home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 200 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  6.9 KB
  1. Path: news.mindlink.net!news
  2. From: genew@mindlink.bc.ca (Gene Wirchenko)
  3. Newsgroups: comp.lang.c++,comp.lang.c,comp.std.c
  4. Subject: Re: Hungarian notation
  5. Date: Sat, 27 Jan 1996 08:32:27 GMT
  6. Organization: MIND LINK! - British Columbia, Canada
  7. Message-ID: <4eco1g$aih@fountain.mindlink.net>
  8. References: <30C40F77.53B5@swsbbs.com> <4d2ok0$69s@beach.and.nl> <4dtv3gINNo9u@keats.ugrad.cs.ubc.ca> <SPENCER.96Jan22113215@zorgon.ERA.COM> <4e1nd8$hv0@solutions.solon.com> <3104bfc8.132251392@nntp.ix.netcom.com> <dewar.822407919@schonberg> <3106260f.224013120@nntp.ix.netcom.com> <4e6oj9$o02@news.xmission.com> <31077335.52859072@nntp.ix.netcom.com> <JSA.96Jan25190824@organon.com> <310842ad.6002240@nntp.ix.netcom.com> <JSA.96Jan26175507@organon.com> <31098190.8106176@nntp.ix.netcom.com>
  9. NNTP-Posting-Host: line105.nwm.mindlink.net
  10. X-Newsreader: Forte Free Agent 1.0.82
  11.  
  12. miker3@ix.netcom.com (Mike Rubenstein) wrote:
  13.  
  14. >jsa@organon.com (Jon S Anthony) wrote:
  15.  
  16. >NOTE:  I've removed all groups from this posting except comp.lang.c
  17. >and comp.lang.c++ and have added cmp.std.c
  18.  
  19. >Since I've added a new group, let me summarize a bit.  The discussion
  20. >revolves around the result of converting a signed integral type to a
  21. >smaller type when the value in the original cannot be represented in
  22. >the new type.
  23.  
  24. >I claim that ISO 6.2.1.2 requires that an implementation actually do
  25. >such a conversion.  The implementor may choose the mapping.  Beside
  26. >the usual throwing away of high order bits, possibilities include
  27. >always using the value 0, or the largest possible value for the new
  28. >type, or, even, a random value.
  29.  
  30.      Or even a random value for your system disk <G>.
  31.  
  32.      Implementation defined means implementation defined, not what you
  33. want it to mean.  I agree that your interpretation sets out reasonable
  34. actions that might be performed.  Please quote chapter and verse on
  35. where the Standard states that implementation defined actions must be
  36. "reasonable" (whatever the hell that is <G>).
  37.  
  38. >However, I claim that a conversion is required -- the implementation
  39. >must come up with a value that can be represented in the new type and
  40. >use that.  It may not do other things like, as one person claimed,
  41. >deleting the system disk even if such action is documented.
  42.  
  43.      Is your claim supported in the Standard?  If it isn't, you're
  44. wasting your time.  What if the conversion results in overflow?
  45.  
  46. >> In article <310842ad.6002240@nntp.ix.netcom.com> miker3@ix.netcom.com (Mike Rubenstein) writes:
  47. >> 
  48. >> > jsa@organon.com (Jon S Anthony) wrote:
  49. >> > 
  50. >> > > In article <31077335.52859072@nntp.ix.netcom.com> miker3@ix.netcom.com (Mike Rubenstein) writes:
  51. >> > > 
  52. >> > > > I think you're reading something into my post that isn't there.
  53. >> > > > 
  54. >> > > > What am I reading into the standard that's not there?  Nothing in my
  55. >> > > > post suggests that defining the result as always 0 is illegal.  In
  56. >> > > > fact, it is clearly legal.
  57. >> > > > 
  58. >> > > > But the standard does impose some restrictions on the definition.  The
  59. >> > > > definition must specify that the subject type is converted to the
  60. >> > > > object type.  It must not produce side-effects.
  61.  
  62.      Why are no side effects permitted?  Chapter and verse, please.
  63.  
  64. >> > > > 
  65. >> > > > Please reread my post; I was responding to the statement that the
  66. >> > > > definition could be to delete the system disk.  That is out of bounds
  67. >> > > > for the definition and I said so.  I did not say that defining the
  68. >> > > > result to be 0 is out of bounds.
  69. >> > > 
  70. >> > > Face it.  You just plain got it wrong.  Deleting the system disk is
  71. >> > > perfectly within bounds.  Stupid, for sure, as no one in their right
  72. >> > > mind would use such a compiler, but perfectly legal.
  73. >> > 
  74. >> > Please cite anything in the standard that supports your position.  I
  75. >> > can find nothing in the standard that gives an implementation that
  76. >> > license.
  77.  
  78.      If "implementation defined" does not qualify as "that licence",
  79. what in your eyes would? 
  80.  
  81. >> > 
  82. >> > Insults do not prove a point -- quotes from the standard do.  I've
  83. >> > shown the passages that support my position.
  84. >> 
  85. >> I don't see any insult here at all.  Sorry if you took it that way.
  86. >> 
  87. >> Here's the relevant passage yet again:
  88. >> 
  89. >>      When a value with integral type is demoted to a signed integer
  90. >>      with smaller size or an unsigned integer is converted to its 
  91. >>      corresponding signed integer, if the value cannot be 
  92. >>      represented the result is implementation defined.
  93. >> 
  94. >> Now, the problem is (as James Kanze has pointed out) that the term
  95. >> "result" which you believe to know the "correct" definition of, is not
  96. >> defined.  Because of this it _could_ be taken as meaning "result of
  97. >> the computation".  You take it as a given that it means "result of the
  98. >> expression", i.e., its value.  But that is not clear, and so an
  99. >> interpretation given the former reading would indeed allow for
  100. >> virtually any sort of behavior as long as that behavior was
  101. >> documented.  As James Kanze pointed out, a very _reasonable_
  102. >> interpretation given this reading of "result" would be to to signal
  103. >> (raise) an exception.
  104.  
  105.      Agreed and this is what is keeping this argument going, eh?
  106.  
  107. >I've not seen Jame's post, but I look forward to seeing it.
  108.  
  109. >But, I don't see how the standard permits throwing an exception.  ISO
  110. >6.2 says
  111.  
  112. >    Several operators convert operand values from one type to 
  113. >    another automatically.  This subclause specifies the result 
  114. >    required from such an implicit conversion, as well as those 
  115. >    that result from a cast operation (an explicit conversion).
  116.  
  117.      What if the conversion results in overflow?
  118.  
  119. >It seems obvious to me that if one uses correctly a construction that
  120. >the standard says converts a value from one type to another, then the
  121. >implementation must convert the value from one type to another -- it
  122. >may not do other things.  By definition (ISO 3.10)
  123. >implementation-defined behavior only applies to a correct program
  124. >construct and correct data.
  125.  
  126.      If it is impossible to convert due to sizing, then the "must" is
  127. rather silly, isn't it?
  128.  
  129.      Would not the normal situation (especially since the point hasn't
  130. been raised previously) imply that the conversion we want done applies
  131. to a correct program construct and correct data?  Why would you assume
  132. anything else?  You are permitted to answer that you may do as you
  133. please because your assumptions are implementation defined <G>.
  134.  
  135. >I'm glad you intended no insult.  I'm afraid I just don't react well
  136. >to ex cathedra statements that I am wrong, particularly when I have
  137. >taken  care to give clear citations that I believe support my
  138. >position.
  139.  
  140.      Yes, but you keep saying "claim" and write as if you are the
  141. Right Hand of God.  So what about your claims!  If they can't be
  142. supported by the Standard, forget it.  Schildt CLAIMS that void main()
  143. is ok.
  144.  
  145. >Michael M Rubenstein
  146.  
  147. Sincerely,
  148.  
  149. Gene Wirchenko
  150.  
  151. C Pronunciation Guide:
  152.      y=x++;     "wye equals ex plus plus semicolon"
  153.      x=x++;     "ex equals ex doublecross semicolon"
  154.  
  155.